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I. REAL PARTY IN INTEREST 

The real party in interest in this appeal is Thomson Licensing Inc., the assignee of 

record. 

II. RELATED APPEALS AND INTERFERENCES 

There are no appeals or interferences that will directly affect, or be directly 
affected by, or have a bearing on the Board's decision in this appeal. 

III. STATUS OF CLAIMS 

The status of all of the claims remaining in the application, claims 1-12 and 13 - 
16 is set forth in Appendix A of this Brief. 
Claim 13 has been canceled. 

Claims 1-12 and 14-16 have been rejected under 35 U.S.C. 103(a) as being 
unpatentable over Manson et al. (US Patent No. 6543051, hereafter referred to as 
"Manson") in view of Pinder (US Patent No. 61 12074, hereafter referred to as "Pinder"). 

Claim 6 has been further rejected under 35 U.S.C. 103(a) as unpatentable over 
Manson in view of Pinder and further in view of Adler (US Patent No. 6505203, 
hereafter referred to as "Adler"). 

IV. STATUS OF AMENDMENTS 

All amendments prior to this Appeal have been entered. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

References to paragraph numbers (OOxx) are to U.S. Published Application Serial 
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No. U. S. 2006/0031582 Al, the published version of this appealed application. 
INDEPENDENT APPARATUS CLAIM 1 

The invention of claim 1 relates to a system for inserting "Alert" information into 
broadcast programming that is transmitted by a program distributor 18 over a program 
distribution network 20 such as a cable TV network (see FIG. 1). The system receives 
"Alert" information (e.g. hazardous weather, terrorist activity, missing person, etc.) in a 
first format comprising one or more SAME ("Specific Area Message Encoding") codes 
and converts the Alert information to a second format (MPEG-2) which is compatible 
with the programming being broadcast via the distribution network (see FIG. 5 and also 
para. 0027). 

The program distributor 18 inserts the converted "Alert" information into the 
broadcast programming via the program distribution network 20 so that the Alert 
message supercedes other transmissions being broadcast over the network (para. 0026 - 
0028) when an alert is to be received. The converted Alert is formatted into an MPEG 
transport packet where a packet identifier (PID) in the header of the transport packet 
identifies the content of the transport packet as being an Alert message instead of being at 
least one of audio information and video information as would be the case for ordinary 
broadcast programming (para. 0021). The Alert message is transmitted to a user when 
geographic data in the message corresponds to (matches) that of the user (para. 0023 - 
0024). 

INDEPENDENT METHOD CLAIM 7 

The language in the specification describing the method steps of the method of 

claim 7 closely follows that of the structural elements of apparatus claim 1 as set forth 
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above. In addition, the method of claim 7 recites the step of "receiving an alert message" 
(e.g. hazardous weather, terrorist activity, missing person, etc.) "in a proprietary format 
comporting to a SAME (i.e. Specific Area Message Encoding) message" (para. 20 - 21). 

Claim 7 further recites "translating the alert message" to a second format (e.g., 
MPEG-2) which is compatible with a broadcast signal used for transmitting broadcast 
programming (see references above and also para. 0027 and FIG. 5). 

The translated alert message is transmitted "with the broadcast programming". 
The translated alert message "is formatted into an MPEG transport packet where the 
packet identifier (PID) in the header of the transport packet identifies the content of the 
transport packet as being an alert message instead of being at least one of audio 
information and video information" as compared with the case for ordinary broadcast 
programming (para. 0021, 0031, 0032). 

The step of transmitting the alert message is further specified as occurring when 
geographic data in the message corresponds to (matches) geographic area corresponding 
to that of a user that receives broadcasting programming from the program distributor 
(para. 0023 - 0024). 

INDEPENDENT METHOD CLAIM 12 

Independent method claim 12 is similar in many respects to independent method 
claim 7 and is supported in large part in the specification in the same manner as claim 7. 

In addition, the method of claim 12 recites the added initial step of "transmitting 
broadcast programming in an MPEG-2 compatible data stream" (para. 0020). 

Claim 12 further recites the step of "receiving the alert message" (e.g. hazardous 

weather, terrorist activity, missing person, etc.) "in a proprietary format which comports 
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to a SAME (i.e. Specific Area Message Encoding) message" (para. 20 - 21). 

Claim 12 further recites "converting the alert message" "formatted into an 

MPEG-2 transport packet where the packet identifier, etc." (see claim 7 above, also para. 
0027 and FIG. 5) ). 

Claim 12 further substantially follows the language of claim 7 set forth above 
relating to matching geographic data in an alert message with the geographic area 
corresponding to a user (see claim 7 above and para. 0023, 0024). 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

A. Claims 1-12 and 14 - 16 have been rejected under 35 U.S.C. § 103(a) as being 
unpatentable (obvious) in view of a combination of Manson in view of certain aspects of 
Pinder. 

B. Dependent claim 6 has been further rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Manson in view of Pinder and further in view of Adler. 
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VII. ARGUMENT 

A. REJECTION OF CLAIMS 1 - 12 and 14 - 16 UNDER 35 U.S.C. § 103(a) 

In the case of the non-final Rejection of all of the remaining claims under 35 
U.S.C. § 103(a), as being obvious in view of a combination of elements of Manson in 
view of Pinder or further in view of Adler (claim 6), it is respectfully submitted that no 
prima facie case of obviousness has been made out by the Examiner based on the recited 
combination(s) of references. 

1. GENERAL STATEMENT OF PROPER BASIS FOR REJECTIONS UNDER 
35 U.S.C.S 103(a) 

In a "Notice" dated October 3, 2007, the Director of the USPTO 
promulgated "Examination Guidelines For Determining Obviousness Under 35 
USC 103 in View of the Supreme Court Decision in KSR International Co. v. 

Telejlex, Inc.", 550 U.S. , 127 S. Ct. 1727, 82 USPQ2d 1385, decided April 

30, 2007 . 

In the "Guidelines", the Director stated: 

"As reiterated by the Supreme Court in KSR, the framework for the objective 
analysis for determining obviousness under 35 U.S.C. 103 is stated in Graham v. 
John Deere Co. Obviousness is a question of law based on underlying factual 
inquiries. The factual inquiries enunciated by the Court are as follows: 

(1) Determining the scope and content of the prior art; 
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(2) Ascertaining the differences between the claimed invention and the prior art; 
and 

(3) Resolving the level of ordinary skill in the pertinent art." 

The "Guidelines" provide specific "rationales" for supporting a legal 
conclusion of obviousness based on combinations of references as follows 
(emphasis added): 

"The key to supporting any rejection under 35 U.S.C. 103 is the clear 
articulation of the reason(s) why the claimed invention would have been obvious. 
The Supreme Court in KSR noted that the analysis supporting a rejection under 35 
U.S.C. 103 should be made explicit, ( emphasis added). The Court quoting In re 
Kahn, [citation omitted] stated that '[Rejections on obviousness cannot be 
sustained by mere conclusory statements; instead, there must be some articulated 
reasoning with some rational underpinning to support the legal conclusion of 
obviousness'. 
Rationales 

(A) Combining prior art elements according to known methods to yield 
predictable results; 

(B) Simple substitution of one known element for another to obtain 
predictable results; 

(C) Use of known technique to improve similar devices (methods, or 
products) in the same way; 

(D) Applying a known technique to a known device (method, or product) 
ready for improvement to yield predictable results; 
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(E) "Obvious to try" - choosing from a finite number of identified, 
predictable solutions, with a reasonable expectation of success; 

(F) Known work in one field of endeavor may prompt variations of it for 
use in either the same field or a different one based on design incentives or other 
market forces if the variations would have been predictable to one of ordinary 
skill in the art; 

(G) Some teaching, suggestion, or motivation in the prior art that would 
have led one of ordinary skill to modify the prior art reference or to combine prior 
art reference teachings to arrive at the claimed invention." . 

The "Guidelines" go on to recognize the continued viability of the TSM 
rationale (item "G") as follows: 

"If the search of the prior art and the resolution of the Graham factual 
inquiries reveal that an obviousness rejection may be made using the familiar 
teaching-suggestion-motivation (TSM) rationale, then such a rejection using the 
TSM rationale can still be made. Although the Supreme Court in KSR cautioned 
against an overly rigid application of TSM, it also recognized that TSM was one 
of a number of valid rationales that could be used to determine obviousness". 

In KSR International Co. v. Tele/lex, Inc. et al., supra, (see Section "B", 
pages 14 - 15 of the published decision), the U. S. Supreme Court discussed this 
requirement of "teaching, suggestion or motivation" and stated: 

"When it first established the requirement of demonstrating a teaching, 
suggestion or motivation to combine known elements in order to show that the 
combination is obvious, the Court of Customs and Patent Appeals captured a 
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helpful insight. See Application ofBergel, 292 F. 2d 955, 956 - 957 (1961). 

In the years since the Court of Customs and Patent Appeals set forth the essence 
of the TSM test, the Court of Appeals no doubt has applied the test in accord with 
these principles in many cases. There is no necessary inconsistency between the 
idea underlying the TSM test and the Graham analysis". 

The "Graham analysis" refers to the three required factual inquiries set out 
in Graham v. John Deere Co. of Kansas City, 383 U. S. 1 (1966) mentioned 
above. 

It is therefore respectfully submitted that under the published guidelines 
incorporating the latest Supreme Court decision (the KSR case) the Examiner is 
required to find all elements of the claims in citable references or sources, to 
identify all missing elements ("ascertain — the differences"); to find such 
references which teach, suggest and/or motivate the person of ordinary skill to 
combine such elements in the manner set forth in the rejected claims, and provide 
a " clear articulation of the reason(s) why the claimed invention would have been 
obvious" (KSR supra, emphasis added) . The KSR opinion requires that 
"rejections on obviousness cannot be sustained by mere conclusory statements; 
instead, there must be some articulated reasoning with some rational underpinning 
to support the legal conclusion of obviousness". In the absence of references 
disclosing all of the claimed elements, and the showing of a teaching, suggestion 
or motivation to combine such claimed elements in the manner claimed, and a 
clear statement and rational analysis of its basis, an obviousness rejection cannot 
stand. 
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To summarize, in order to establish a prima facie case of obviousness, all 
of the foregoing basic criteria must be met. That is, the prior art references when 
combined must teach or suggest all of the claim limitations. There must be some 
suggestion or motivation, either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art, to modify the references or 
to combine them as claimed. Finally, there must be a reasonable expectation of 
success for the proposed combination of elements. The teaching or suggestion to 
make the claimed invention and the reasonable expectation of success must both 
be found in the prior art, and not based on the applicant's own disclosure. In re 
Vaeck, 20 U.S.P.Q.2d 1438 (Fed. Cir. 1991). 

Patent examiners cannot rely on their own knowledge as a basis for 
rejecting patent applications without the citation of specific evidence (references) 
having a teaching, suggestion or motivation to modify a reference or to combine 
two or more references ; In re Lee, 277 F.3d 1338, 1345 (Fed. Cir. 2002). 

The examiner bears the burden of establishing a prima facie case of 
obviousness and "can satisfy this burden only by showing some objective 
teaching in the prior art or that knowledge generally available to one of ordinary 
skill in the art would lead that individual to combine the relevant teachings of the 
references." In re Fine, 5 U.S.P.Q.2d 1596, 1598 (Fed. Cir. 1988, emphasis 
added). 

Absent the elements or the showing of a teaching, suggestion or 
motivation to combine such elements as claimed, an obviousness rejection cannot 
stand. 
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2. THE DISCLOSURE IN U.S. PATENT NO. 6,543,051 - MANSON ET AL. 



Manson describes a system for inserting an emergency alert message 
(EAM) into a digital subscriber television system. Like the present invention, 
Manson' s digital subscriber television system 201 "uses MPEG transport streams 
for delivery of video, audio and data entertainment services" (col. 2, lines 57 - 
60). These MPEG transport streams convey the ordinary TV signals in a 
customary manner. As the Examiner has recognized, Manson transmits "MPEG 
formatted information from the application servers - — as the in-band data" 
(rejection, page 3). Thus, "in-band data" is the main entertainment services 
information or TV programming. 

However, as will be shown below, the Examiner incorrectly concludes that 
Manson discloses converting alert information from a SAME (Specific Area 
Message Encoding) code format to a second format "compatible with the 
programming broadcasted via the program distribution network" (claim 1) or 
"compatible with a broadcast signal used for transmitting the broadcast 
programming" (claim 7). Manson says only that his system converts alert 
messages into a text file (or an audio file) "compatible with the digital subscriber 
system , such as an HTML or ASCII display file" (or RIFF Wave or AIFF audio 
file, as the case may be) - see col. 4, lines 55 - 65, but does not refer to 
compatible with the programming broadcast. 

Further, the Examiner incorrectly concludes that Manson discloses 
inserting "the converted alert into the broadcast programming" (claim 1, also see 
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claim 7 "transmitting the translated alert message with the broadcast 
programming", and claim 12 "converting the alert message into data that is 
inserted into packets — MPEG-2 data stream") in Manson's "in-band delivery 
path" (rejection, bottom of page 3). It will be demonstrated below that Manson 
discloses an "out-of-band" delivery path for the alert message and does not 
disclose inserting the alert message "into the broadcast programming". Finally, 
the Examiner incorrectly concludes (without any suggestion from Manson) that 
"the converted alert is formatted into an MPEG transport packet" (claim 1, see 
also similar language in claim 7 and claim 12 above) - see rejection, top of page 4 
- which is processed via Manson's "in-band delivery path". MPEG transport 
packets in an in-band delivery path is clearly not what Manson discloses. 

The cited Manson patent itself is silent regarding which delivery path (in- 
band or out-of-band) is used to pass alert information to a subscriber. However, at 
column 2, lines 32 - 39 of the cited Manson patent, Manson identifies and 
incorporates by reference his U.S. Provisional Patent Application No. 60/143,835 
(the "priority" application). 

Copies of relevant hand numbered pages 5, 37 - 39 and 42 of that priority 
document, as they appear in the PAIR database of the USPTO, are attached as 
evidence in APPENDIX B of this BRIEF. 

On page 5 of the priority application, Manson provides a diagram of an 
"MMM System", i.e. a MultiMedia Message system, including an "Emergency 
Alert Receiver Server (EARS)" coupled to a "MultiMedia Message Server 
(MMMS)". A "DHCT" (Digital Home Communications Terminal) is provided at 
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the end of the illustrated signal path. These elements are also described in the 
cited Manson patent. 

On page 37 of the priority document ("2.1.6.1 MMM Request"), the 
manner of sending an Emergency Alert Message (EAM) in Manson' s system is 
described. Manson specifically states there that "These files will be sent through 
an out of band data carousel — " (emphasis added). Following this statement, 
Manson' s "format of the payload" (the Emergency Alert Message) is presented in 
a table on pages 38 -39 of the priority document. This format corresponds 
substantially to what is shown in Table I of the cited Manson patent as "An 
exemplary embodiment of a digital emergency alert message of the present 
invention" of the Manson patent. Manson repeatedly refers to his format of Table 
1 as a "unique format" (col. 5, lines 6 - 20) and, contrary to the Examiner's stated 
position, never mentions anything about an MPEG format in connection with his 
alert messages. 

Thus, it is clear from the priority application that alert information is sent 
by Manson via an "out-of-band" path using a "unique format" (not MPEG).. The 
Examiner's conclusion that Manson discloses "the application servers distribute 

the converted emergency alert message with the television program with in- 

band delivery path" (rejection, bottom of page 3, emphasis added) is incorrect and 
contrary to what Manson states in the priority application (which is incorporated 
by reference into the cited Manson patent). 

Thus, Manson does not disclose that he distributes the alert message "with 
the television program" using the "in-band delivery path", does not describe that 
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"The program distributor inserts the converted alert into the broadcast 
programming", and does not produce a "converted alert - formatted into an 
MPEG transport packet" as assumed and asserted by the Examiner in the 
rejection. There is simply no support for the Examiner's stated conclusions. 

The foregoing analysis is submitted to be the appropriate required 
comparison of the claimed invention with the prior art as set forth in the 
obviousness "Guidelines" set forth above. The Examiner's analysis is submitted 
to be incorrect and the Examiner has not found all elements of the claimed 
combinations in the cited Manson reference. 

Rejected independent method claims 7 and 12 are submitted to be 
patentable for the reasons presented above in distinguishing independent 
apparatus claim 1 over Manson. 

2. THE DISCLOSURE IN U.S. PATENT NO. 6.1 12.074 - PINDER 

Pinder is cited by the Examiner to supply elements of the rejected claims 
which are missing from Manson. However, none of the elements pointed out 
above as missing from Manson can be found in Pinder. In fact, Pinder has nothing 
to do with broadcast programming distribution or MPEG formats or inserting alert 
information into such signals. Pinder does not fill any of the gaps in Manson 
pointed out above and cannot be combined in any manner with Manson to render 
obvious the combinations of claim elements discussed above. 
Specifically, Pinder only describes a cell telephone system for voice messaging 
which is augmented with transmission of emergency local weather information 
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(Pinder, col. 1, lines 20 - 23) to specific cell antenna towers (sites) located in 
threatened geographic areas. The system has nothing to do with broadcast 
programming, broadcast signal formats or image displays. 

In the rejection (pages 4 - 5), the Examiner's entire reliance on Pinder is 
set forth as follows: 

"The radio communication system obtains event and locality information, and 
uses the locality information to transmit the event information to subscribers of 
that system potentially affected by the event (see, e.g., abstract and figure 3); and 
Transmitting the alert information in the form of SAME (a NOAA station 
broadcasts weather and emergency event information in a digital message using a 
Specific Area Message Encoding (SAME) protocol, see, e.g. col. 2, lines 23-41 
and figure 1). 

It would be obvious to combine Manson with Pinder in order the system of 
Manson to leave uninterested geographic region undisturbed and avoid a "Boy 
Who Cried Wolf problem for the affected geographic region". 

It is apparent from the language of the rejection quoted immediately above 
that Pinder discloses nothing which corresponds to the claim elements missing 
from Manson as pointed out above. Furthermore, there is no teaching, suggestion 
or motivation disclosed in either reference (or identified by the Examiner) of how 
or why one could combine anything from the two references to bridge the 
informational gaps between the two. 

Pinder relies on the characteristic of cell phone systems that each "site" 
(antenna tower) in a cell phone system is inherently limited to sending signals a 
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relatively short distance and the recipients of an emergency alert message can 
therefore be geographically selected. However, as described, this system would 
omit sending alert messages to cell phone users in the threatened area that were 
passing through and, probably, also cell phone users normally in the threatened 
area who were outside of it when an alert message was sent. Pinder operates in a 
substantially different environment than Manson (or the present invention), using 
different signal formats and as such, is not combinable with Manson to provide a 
useful system. As noted above, there is no teaching, suggestion or motivation in 
either Pinder or Manson to combine anything from these two references. The 
Examiner is simply using Appellants' disclosure as a roadmap to find bits and 
pieces of the presently claimed invention. Such a piecemeal attempt to reconstruct 
the claimed invention is not an appropriate basis for a finding of obviousness. 

It is submitted that no basis has been presented on which a prima facie 
case of obviousness may be established as to any of independent claims 1 , 7 and 
12 based on what is disclosed separately by each of Manson and Pinder. 

3 . THE DISCLOSURE IN U.S. PATENT NO. 6.505,203 - ADLER 

Adler is cited by the Examiner to supply a single element of dependent 
claim 6 which the Examiner acknowledges is missing from both Manson and 
Pinder. Specifically, the Examiner states: 

"Manson in view of Pinder do not explicitly teach the alert class is including an 
alert related to a missing person." 

However, Adler does not disclose any of the other several elements of the 
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rejected independent claim 1 (from which claim 6 depends) which have been 
pointed out above as missing from Manson and Pinder. 

Adler relates to a significantly different internet based information 
handling system using a predetermined network of selected e-mail recipients in an 
analytically determined geographic area to quickly spread a missing person's alert 
in that selected geographic area. Since Adler is concerned only with missing 
persons, his system has nothing to do with broadcasting such things as a weather 
alert to everyone in a geographic area (as described in claim 1). There is no 
teaching, suggestion or motivation in any of the references to combine what Adler 
discloses with Manson and Pinder to even suggest or arrive at all elements of 
claim 1. Therefore, claim 6, like claims 1, 4 and 5 from which it depends, cannot 
be found to be obvious over any combination of Manson in view of Pinder and 
further in view of Adler. 

VIII. CONCLUSION 

It is respectfully submitted that there is no combination of Manson with 
Pinder which can be said to disclose, teach, suggest to or motivate a person of 
ordinary skill to combine these two references to arrive at any of the claimed 
apparatus or method combinations of claims 1-12 and 14-16. 

The Examiner has not identified any reference or combination of 
references which discloses or suggests all elements of any of the independent 
claims 1, 7 or 12. In view of the significant differences between Appellants' 
claimed invention and the method/system disclosed by any of Manson, Pinder and 
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Adler, and the fact that those references do not provide any teaching, suggestion 
or motivation for modifying any of their disclosures so as to arrive at Appellants' 
claimed methods/apparatus, no prima facie basis has been established for 
supporting a conclusion of obviousness of any of claim 1-12 and 14 - 16. 

The Examiner has attempted to bridge the gaps between the cited 
references Angal and the rejected claims by using Appellants' disclosure as a 
roadmap. However, as shown above, the gap between the claims and what the 
references disclose has not been closed and there is no combination of these 
references which meets the appealed claims or renders the appealed claims 
obvious. 

Appellants therefore assert that claims 1-12 and 14 - 16 are patentable. 
Appellants request the reversal of the rejection of all claims and allowance of 
claims 1 - 12 and 14 - 16. 

IX. CLAIMS APPENDIX 

A complete listing of the claims involved in this appeal is attached hereto 
as Appendix A. 

X. EVIDENCE APPENDIX 

Appellant has submitted additional evidence comprising five (5) pages of 
U.S. Provisional Application No. 60143385, a Priority application for Manson, 
which are included in Appendix B attached. 
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XI. RELATED PROCEEDINGS APPENDIX 



Appellant states that there are no relevant related proceedings and, an 
Appendix C is hereby attached indicating '"none." 



Respectfully submitted, 
/Joel M. Fogelson/ 

Date:March 30, 2010 Joel M. Fogelson 

Phone No. 609-734-6809 
Reg. No. 43,613 

Patent Operations 

Thomson Licensing Inc. P.O. Box 5312 
Princeton, New Jersey 08543-53 12 

Attachments: 

Appendix A: Claims on Appeal 
Appendix B: Evidence 
Appendix C: Related Proceedings 



APPENDIX A 
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CLAIMS ON APPEAL 



The following is a listing of all claims, pending, or canceled, incorporating all 
elements and revisions to date. All non-canceled claims are on appeal, canceled claims 
being canceled without prejudice or disclaimer. 

1 . (amended) A system for inserting alert based information into broadcast 
programming over a program distribution network comprising: 

a program distributor that transmits the broadcast programming over the 
program distribution network; wherein 

the program distributor receives the alert based information and converts 
the alert from a first format comprising at least one SAME code to a second format 
compatible with the programming broadcasted via the program distribution network; and 

the program distributor inserts the converted alert into the broadcast 
programming via the program distribution network when a geographic data in said alert 
message matches a geographic region corresponding to a user that receives said 
broadcasting programming from said program distributor, and said alert based 
information is not transmitted when said geographic data in said alert message does not 
match said geographic region corresponding to said user; 

the converted alert is formatted into an MPEG transport packet where the 
packet identifier (PID) in the header of the transport packet identifies the content of the 
transport packet as being an alert message instead of being at least one of audio 
information and video information. 
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2. (amended) The system of Claim 1, wherein the converted alert and the 
programming broadcasted via the program distribution network are capable of being 
rendered on at least one of a display device and an audio based device. 

3. (amended) The system of Claim 1, wherein the alert based information 
received is an audible based message that is converted into data capable of being 
broadcasted over the program distribution network for rendering on an audio device. 

4. (original) The system of Claim 1, wherein the program distributor adds 
supplemental information to the alert based information for broadcast; the supplemental 
information selected is based on data in the alert based information. 

5. (original) The system of Claim 4, wherein the supplemental information 
selected is determined by the geographic region corresponding to an alert based 
information and the alert class of the alert based information. 

6. (amended) The system of Claim 5, wherein the alert class is including an 
alert related to a missing person. 

7. (amended) A method for inserting alert based information into broadcast 
programming over a program distribution network comprising the steps of: 

receiving an alert message in a proprietary format comporting to a SAME 

message; 
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translating the alert message from the proprietary format into a second 
format compatible with a broadcast signal used for transmitting the broadcast 
programming; and 

transmitting the translated alert message with the broadcast programming, 
when a geographic data in said alert message matches a geographic area corresponding to 
a user that receives said broadcasting programming from said program distributor, and 
said alert based information is not transmitted when said geographic data in said alert 
message does not match said geographic area corresponding to said user, wherein 

the translated alert message is formatted into an MPEG transport packet 
where the packet identifier (PID) in the header of the transport packet identifies the 
content of the transport packet as being an alert message instead of being at least one of 
audio information and video information. 

8. (amended) The method of Claim 7, wherein the alert message received is 
an audible based message that is converted in data capable of being broadcasted over a 
program distribution network for rendering on an audio device. 

9. (amended) The method of Claim 7, wherein supplemental information is 
added to the alert message; the supplemental information selected is based on data in the 
alert information. 
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10. (amended) The method of Claim 9, wherein the supplemental information 
selected is determined by the geographic region corresponding to the alert based 
information and the alert class of the alert based information. 

11. (amended) The method of Claim 7, wherein the programming is 
broadcasted in an MPEG compatible data stream. 

12. (amended) A method for translating a received alert message into a 
format capable of being broadcasted as part of a data stream comprising the steps of: 

transmitting broadcast programming in an MPEG-2 compatible data 

stream; 

receiving the alert message in a proprietary format which comports to a 
SAME message; and 

converting the alert message into data that is inserted into packets used for 
transmitting the MPEG-2 compatible data stream when a geographic data in said alert 
message matches a geographic area corresponding to a user that receives said 
broadcasting programming from said program distributor, and said alert based 
information is not transmitted when said geographic data in said alert message does not 
match said geographic area corresponding to said user, wherein 

the converted alert message is formatted into an MPEG-2 transport packet where 
the packet identifier (PID) in the header of the transport packet identifies the content of 
the transport packet as being an alert message instead of being at least one of audio 
information and video information. 
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13. (canceled). 



14. (amended) The method of Claim 12, wherein the alert message received is 
an audible based message that is converted into data capable of being broadcasted over 
the a program distribution network for rendering on an audio device. 

15. (amended) The method of Claim 12, wherein supplemental information is 
added to the alert message; the supplemental information selected is based on data in the 
alert information. 

16. (amended) The method of Claim 15, wherein the supplemental 
information selected is determined by the geographic region corresponding to the alert 
based information and the alert class of the alert message. 
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APPENDIX B 



EVIDENCE 



U. S. Provisional Patent Application No. 60/143835, filed July 14, 1999 (available on 
PAIR, USPTO website); 

B-l Page 5 (hand numbered) entitled "Appendix A - MMM System Diagram: 

B-2 Page 37 (hand numbered) heading "2.1.6 Multimedia Message Server (MMMS)" 

including reference to "out of band data carousel"; 

B-3 Page 38 (hand numbered) data table depicting a digital message format; 
B-4 Page 39 (hand numbered) continuation of table on page 38; 

B-5 Page 42 (hand numbered) heading "2.1.6.2 MMMConfig Request" including 
reference to (out-of-band) "data carousel". 
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APPENDIX C 
RELATED PROCEEDINGS 
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SC1ENTIFIC-A TLANTA P ROPRIETA RY INFORMATION (when completed) 

Appendix A 
MMM System Diagram 
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m- 
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Byte 


Field Name 








Release 
1 1 










field. 
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AlertLEDDuration 


a 




This field deiemimrs the lengdi in seconds of 

field is only applicable for the options of 
ma_Lighi, m»_HBoth and maTBoih inihe 
mesaeeAtert field. 


NA 


28 


AlertlEDPenod 


8 




This field determines how often in seconds the 
blinking interval is repeated. This field is only 
applicable (or the opnons of naLight, 

field *" m m,SS * ?CA,en 


NA 


29 


alertLength 


8 




This field determines the length of the alertText 
field. 


NA 


30.31 


reserved 


16 








32 


AlertContent 






This field determines a 2-iine text if the 
messagcAiert field is enhet ma Text . 
rra_HTMi,ma TBoth,orna HBoih. 


NA 



2.1.6.2 MMMConfig Request 

When an MMMConfig Request is received by the MMMS, it will first update the database 
and creates/rebuilds/removes the tiles, if needed. If the MMMConfig Request is for a default 
configuration, a one way UNPassThruMessage Request(message #8506) is sent to all 
DHCTs indicating that the default configuration file has been modified. The latest version 
number is sent in this message. 

There could be one or more configurations in one configuration file. The format of this file 
is given in the next section. These configuration files will be stored under 'bfs://MMMT 
directory. The MMMConfig files will be sent through the data carousel, specified in the 



2.1.6.3 MMMConfig File Format 



Byte 


Field Name 


Length 
(bits) 


Range 


Description 


O.J 


version 


32 














4 


aumConfigs(n) 


16 




This field indicated how many conjiguranons reside in this 




Index! 


16 




This field indicates the first configaanon in this file in bvtes 
from the top of the file. 
















36 




This field indicates the offset of the last configuration file m 
bytes from ibe lop of the file. 




Filler 


0orl6 




This field is a filler to cause the configuration ifau to suit on 
a word boundary byte. 


boundary) 


<ConfigData 1> 






This field indicates the content of the first configuration. The 
format of this field is given in the previous ubic. 












4*y 


<dnfigDma n> 






This field tndkates the contort of the last configuration. The 
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2.1.6 Multimedia Message Server (MMMS) 

He MMMS processes two types of requests: MMM Request and MMMCfs Request. These 
requests are sent to the MMMS through a CORBA interface. Upon the start up of the 
MMMS, it will recollect the default configuration parameters and create a default file for 
DHCTs (the format of this configuration is given in the next section). These steps are taken, 
when MMMS starts: 

• Collect all default configurations (Type is set to Defiant) for all categories. 

• Create the "DfltConfig-dat" file based on the above defaults. 

• Mount the file on the bfeZ/MMM/ directory to be sent out on a configurabl e data 
carousel 

• Notify the DHCTs through UNPassThruMessage(#8506) about the default 
configuration file. Specify the latest version in the message. 

• Wait for any request from the system through the CORBA interface. 
The following sections describes in detail the process when a request is received. 



hi 2.1.6.1 MMM Request 

yi 

. . In the first phase, only Emergency Alert Message(EAM) is sent in this request. When the 

.0 MMMS receives an EAM, the appropriate configuration information is retrieved from the 

Sj database and tagged onto the end of this MMM request Then through a one way 

:J=fc SAMSignallingPassThruMessage, the MMM resident applications in all DHCTs are invoked 

=£ (this is a one way global message) with the given MMM request payload. 

iyfj If the AudioContent or DisplayContent fields are URL locations, these files vvill be mounted 

on the U bfs://MMM" directory. These files will be sent through an out of band data carousel, 
specified in the configuration parameter, for this configuration. 

If the ConfigContent field is a URL location, this file will be mounted on the "bfs://MMM" 
directory. This file will be sent through the data carousel, specified in the configuration 
parameter, for this configuration. 

An MMM request will be sent out several times with a delay between each repeat. The 
number of repeat times and the delay between each repeat are configurable per configuration. 

The format of the payload in the SAMS ignallingPassThru Message is given as below: 
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8-3 







(bits)* 




Description 




ntsgld 


32 




This field indicates which version of the configuration tiie 
should be used. 


4.-7 


orignatianTime 


32 




Origination time of this message in number of seconds from 
January 1, 1970 in GMT. 


8-9 


duration 


16 




The length of the event in nrinutes. 


10..11 


display-Offset 


16 




This field specifies the offset in bytes of the display Content 
from the start of this message. 


I2..13 


dhplayLength 


16 




This field specifics the length of the display Corner.! field in 


14-15 


audioOffset 


16 




Thts field specifies the offset in bytes of the amiioConem 
field from the start of this message. 


16..17 


audioLenpk 


32 




This field specifies the length of the audioComent field in 


18 


dispiayFlag 


8 


O.A 


Thts field specifies the nature of dispiayConiem and 
MsplayOgsel fields. 

0: dfjlone means that there is no text message and the 
content olinc dispieyOjfsa >ml dispiayConiem fields are not 
applicable. This is used when there a only an audio 

field is an ASCII file and a default foreground, background, 

font, and size wEB be used to display the message. 

2: dfJITML means the content of the displayConKni field is 

an WML file. <NA in release 1_2> 

3: dfJJRL means that the content of the display-Content field 

is a URL location of an HTML file on the 8FS server: 

4: dfjlodt, means display a black screen and the content of 

the display-Offset and tSsplayConterj fields are not 

applicable. <NA in release 1,2> 


19 


audioFlag 


8 


0.JX 


This field specifies the nature of audiodmtent and 
audioOffset field-. 

0: afjione means do not override the audio of the current 
fields are not applicable. 

I : of Alt': means the content of audioContent is an A IF 

formal audio samples. < NA in release 1 2> 

t af_WA Y: means the content of audioContent is and WAV 

format audio samples, <NA in release \2> 

3: af URL means that the content of the audioCanieni field 

is the URL location of an audio file. 

4: afJSilence means pkty silence over the current 

application and the content of audioOffset and audioContent 

fields arc not applicable- < NA in release 1_2> 


20 


configFlag 


S 


0..! 


This field specifies ihe nature ol configOmtert field. 
0- cfJJRL means (he content of conJigConlent is the name 
and URL of the configuration to be used with thts M.MM. < 
NA in release 12> 

1: cf_Data means the content of amfigConieKt is the actual 
configuration data to be used with this MMM. 




configLength 


3 




This field indicate the length of the confi%Caniem only if it 
iscf_URL. 



r3 



B-4 



Byte 


Field Name 


Length 

(bits) 


Range 


Description 


22... 


<configContent> 






This field specifies either the actual confiffliration data or the 
name and URL location of the configuration depending on 
the option given in the configFlag ficld. 


(word 
boundary) 


<dLsplayConiem> 






This field specifies either the actual HTML MMM or the 
URL location of the MMM depending on the option siven 
in the displayFlag field. 


4*m... 
boundary) 


<aueBeC<mtert(> 






This ficM specifies the URL location of the audio tile il the 
option in audioFleg field is of URL. If it is any other value 
this Held has a length of zero and it :s not applicable. 



